Proxy, Registration and Authentication Parameters

Enables the use of Proxy Set ID 0 (for backward compatibility).

Note:

Defines the Home Proxy domain name. If specified, this name is used as the Request-URI in REGISTER, INVITE and other SIP messages, and as the host part of the To header in INVITE messages. If not specified, the Proxy IP address is used instead.

The valid value is a string of up to 49 characters.

Note: The parameter functions together with the [UseProxyIPasHost] parameter.

Enables the use of the proxy server's IP address (in dotted-decimal notation) as the host name in SIP From and To headers in REGISTER requests.

If the parameter is disabled and the device registers to an IP Group (i.e., proxy server), it uses the string configured by the ProxyName parameter as the host name in the REGISTER's Request-URI and uses the string configured by the IP Groups table parameter, SIPGroupName as the host name in the To and From headers. If the IP Group is configured with a Proxy Set that has multiple IP addresses, all the REGISTER messages sent to these proxies are sent with the same host name.

Note: If the parameter is disabled and the ProxyName parameter is not configured, the proxy's IP address is used as the host name in the REGISTER Request-URI.

Enables the device to assign a random string value for the user part of the SIP Contact header in the REGISTER message (generated by the device) for new user Account registrations with the device.

The string includes letters and may include numbers, but it always begins with a letter. The string is unique to each Account. An example of a randomly assigned user part is shown (in bold) below:

Contact: <sip:HRaNEmZnfX6xZl4@pc33.atlanta.com>

The device stops using the random user part in the following scenarios:

To configure Accounts, see Configuring Registration Accounts.

Determines whether the device switches back to the primary Proxy after using a redundant Proxy.

Note: To use this Proxy Redundancy mechanism, you need to enable the keep-alive with Proxy option, by setting the parameter EnableProxyKeepAlive to 1 or 2.

Defines the interval (in seconds) at which the device performs DNS resolution for Proxy Sets that are configured with an FQDN (host name) to translate (resolve) it into IP addresses. The device maintains a cache of DNS resolutions, and will use cached responses as long as the TTL has not expired. If the TTL is expired, a new DNS request is sent to the DNS server.

For example, if configured to 60, the device queries the DNS server every 60 seconds. If successful, the device refreshes the Proxy Set’s list of DNS-resolved IP addresses.

The valid value is 0, or 5 to 2,000,000. The default is 60. The value 0 disables periodic DNS queries and DNS resolution is done only once - upon device restart, device power up, or new and modified configuration.

The device caches the DNS-resolved IP addresses of the last successful DNS query of a Proxy Set, which is used if the DNS server goes offline. This functionality occurs regardless of the setting of the [DNSCache] parameter.

Enables the device to cache (store) DNS-resolved IP addresses of the last successful DNS query of entities (e.g., for Remote Web Services, Access List, and LDAP servers) that are configured with an FQDN. The device clears every entry in the cache 30 minutes after their DNS time-to-live (TTL) value expires.

When enabled and the DNS server doesn't respond (for whatever reason) to the device's DNS query request, instead of taking the entity offline, the device reuses the cached DNS-resolved addresses, thereby maintaining call service. In such a scenario, the device continues to query the DNS server every 10 seconds. However, if the DNS server is still not responding after the device has cleared the cached DNS-resolved IP addresses, the device considers the entity as offline.

Enables the device to fallback to the Tel-to-IP Routing table for call routing when proxy servers are unavailable.

Note: To enable the redundant Proxy mechanism, configure the [EnableProxyKeepAlive] parameter to 1 or 2.

Enables the device to route calls according to the Tel-to-IP Routing table instead of Proxy server.

Enables the device to send SIP requests and responses through a Proxy server.

Note: The parameter is applicable only if a Proxy server is used (i.e., [IsProxyUsed] parameter is configured to 1).

Defines the routing mode after call redirection (i.e., a 3xx SIP response is received) or call transfer (i.e., a SIP REFER request is received).

Note:

Enables the use of DNS Naming Authority Pointer (NAPTR) and Service Record (SRV) queries to resolve Proxy and Registrar servers and to resolve all domain names that appear in the SIP Contact and Record-Route headers.

Note:

Global parameter that defines the DNS query record type for resolving the Proxy server's configured domain name (FQDN) into an IP address.

Note:

Defines if the device's IP address, proxy's IP address, or device's name is used as the host part for the Request-URI in keep-alive SIP OPTIONS messages sent to the proxy (if enabled). The device uses the OPTIONS messages as a keep-alive with its primary and redundant SIP proxy servers. Proxy keep-alive by SIP OPTIONS is enabled per Proxy Set, by configuring the 'Proxy Keep-Alive' parameter to Using OPTIONS (see Configuring Proxy Sets).

Defines how long the device waits (in seconds) before re-sending a SIP OPTIONS keep-alive message to the proxy after the device considers the proxy as offline. It considers the proxy as offline after all the device's retransmissions (configured by the Proxy Set parameter 'Failure Detection Retransmissions') have failed.

The valid value range is 1 to 3600. The default is 1.

Note:

When using UDP as the transport protocol, the device retries failed transmissions to a proxy server according to the Proxy Set parameter 'Failure Detection Retransmissions'. However, when the failed attempt receives an ICMP error (which indicates Host Unreachable or Network Unreachable) as opposed to a timeout, it may be desirable to abandon additional retries in favor of trying the next IP address (proxy server) in the Proxy Set. This is often desirable when Proxy Hot Swap is enabled.

Defines the username for registration and Basic/Digest authentication with a Proxy/Registrar server.

The valid value is a string of up to 60 characters. By default, no value is defined.

Note:

Defines the password for Basic/Digest authentication with a Proxy/Registrar server. A single password is used for all device ports.

The default is 'Default_Passwd'.

Note:

Defines the Cnonce string used by the SIP server and client to provide mutual authentication.

The value is free format, i.e., 'Cnonce = 0a4f113b'. The default is 'Default_Cnonce'.

Enables local caching of SIP message authorization challenges from Proxy servers.

The device sends the first request to the Proxy without authorization. The Proxy sends a 401/407 response with a challenge for credentials. The device saves (caches) the response for further uses. The device sends a new request with the appropriate credentials. Subsequent requests to the Proxy are automatically sent with credentials (calculated from the saved challenge). If the Proxy doesn't accept the new request and sends another challenge, the old challenge is replaced with the new one. One of the benefits of the feature is that it may reduce the number of SIP messages transmitted through the network.

Note:

Enables the device to register to a Proxy/Registrar server.

Note:

Defines the Registrar domain name. If specified, the name is used as the Request-URI in REGISTER messages. If it isn't specified (default), the Registrar IP address, or Proxy name or IP address is used instead.

The valid range is up to 100 characters.

Note: The parameter is applicable only to the Gateway application.

Defines the IP address (or FQDN) and port number (optional) of the Registrar server. The IP address is in dotted-decimal notation, e.g., 201.10.8.1:<5080>.

Note:

Determines the transport layer used for outgoing SIP dialogs initiated by the device to the Registrar.

Note:

Defines the time interval (in seconds) for registering to a Proxy server. The value is used in the SIP Expires header. The parameter also defines the time interval between Keep-Alive messages when the parameter EnableProxyKeepAlive is set to 2 (REGISTER).
Typically, the device registers every 3,600 sec (i.e., one hour). The device resumes registration according to the parameter RegistrationTimeDivider.

The valid range is 10 to 2,000,000. The default is 180.

Defines the re-registration timing (in percentage). The timing is a percentage of the re-register timing set by the Registrar server.

The valid range is 50 to 100. The default is 50.

For example: If the parameter is set to 70% and the Registration Expires time is 3600, the device re-sends its registration request after 3600 x 70% (i.e., 2520 sec).

Note: The parameter may be overridden if the parameter RegistrationTimeThreshold is greater than 0.

Defines the time interval (in seconds) after which a registration request is re-sent if registration fails with a 4xx response or if there is no response from the Proxy/Registrar server.

The default is 30 seconds. The range is 10 to 3600.

Note: Registration retry time can also be configured with the MaxRegistrationBackoffTime parameter.

Defines a dynamic time-to-wait interval before the device attempts to register the SIP entity again after a registration failure. The parameter is applicable only to registrations initiated by the device on behalf of SIP entities (for example, User Info, Accounts, Endpoints or the device itself) with a SIP proxy server (registrar).

The valid value is 0 to 3000000 (i.e., 3 million seconds). The default is 0 (i.e., disabled).

In contrast to the RegistrationRetryTime parameter, which defines a fixed time to wait between registration attempts due to registration failure, this parameter configures the device to increase the time-to-wait interval for each subsequent registration attempt (per RFC 5626, Section 4.5) for a specific registration flow. In other words, the interval changes between registration attempts.

The parameter operates together with the RegistrationRetryTime parameter. When the MaxRegistrationBackoffTime parameter is configured, the wait-time before another registration attempt increases after each failed registration (until it reaches the maximum value specified by the parameter).

The device uses the following algorithm to calculate the incremental augmented wait-time between each registration attempt:

Wait Time = min (max-time, (base-time * (2 ^ consecutive-failures)))

Where:

For example, if max-time is 1800 seconds and base-time is 30 seconds, and there were three consecutive registration failures, then the upper-bound wait time is the minimum of (1800, 30*(2^3)), which is (1800, 240) and thus, the minimum of the two values is 240 (seconds). The actual time the device waits before retrying registration is computed by a uniform random time between 50% and 100% of the upper-bound wait time (e.g., for an upper-bound wait-time of 240, the actual wait-time is between 120 and 240 seconds). As can be seen from the algorithm, the upper-bound wait time can never exceed the value of the MaxRegistrationBackoffTime parameter.

Defines a threshold (in seconds) for re-registration timing. If the parameter is greater than 0, but lower than the computed re-registration timing (according to the parameter RegistrationTimeDivider), the re-registration timing is set to the following: timing set by the Registration server in the SIP Expires header minus the value of the parameter RegistrationTimeThreshold.

The valid range is 0 to 2,000,000. The default is 0.

Enables immediate re-registration if no response is received for an INVITE request sent by the device.

Note: The parameter is applicable only to the Gateway application.

Enables the device to perform SIP re-registration upon TCP/TLS connection failure.

Defines the user part in the From and To headers in SIP REGISTER messages. If no value is specified (default) for the parameter, the [UserName] parameter is used instead.

Note:

Defines the device's registration and authentication method.

Note:

Enables setting the , or entire device (i.e., all endpoints) to out-of-service if registration fails.

If registration is per endpoint (i.e., 'Registration Mode' parameter is configured to Per Endpoint) or per Account (see Configuring Trunk Group Settings) and a specific endpoint/Account registration fails (SIP 4xx or no response), then that endpoint is set to out-of-service until a success response is received in a subsequent registration request. If registration is per the entire device (i.e., 'Registration Mode' parameter is configured to Per Gateway) and registration fails, all endpoints are set to out-of-service.

Note:

Defines if the device sends a registration request (SIP REGISTER) to a Serving IP Group (SIP registrar), based on the Trunk Group's status (in-service or out-of-service).

Note:

Enables the device to perform explicit unregisters.

Note: The REGISTER-specific Contact header field value of "*" applies to all registrations, but it can only be used if the Expires header field is present with a value of "0".

Enables the inclusion of the SIP Authorization header in initial registration (REGISTER) requests sent by the device.

The Authorization header carries the credentials of a user agent (UA) in a request to a server. The sent REGISTER message populates the Authorization header with the following parameters:

For example:

Authorization: Digest username=alice_private@home1.net, realm=”home1.net”, nonce=””, response=”e56131d19580cd833064787ecc”

Note: This registration header is according to the IMS 3GPP TS24.229 and PKT-SP-24.220 specifications.

Enables the inclusion of the SIP Route header in initial registration or re-registration (REGISTER) requests sent by the device.

When the device sends a REGISTER message, the Route header includes either the Proxy's FQDN, or IP address and port according to the configured Proxy Set, for example:

Route: <sip:10.10.10.10;lr;transport=udp>

or

Route: <sip: pcscf-gm.ims.rr.com;lr;transport=udp>

Enables the use of the carriage-return and line-feed sequences (CRLF) Keep-Alive mechanism, according to RFC 5626 “Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)” for reliable, connection-orientated transport types such as TCP.

The SIP user agent/client (i.e., device) uses a simple periodic message as a keep-alive mechanism to keep their flow to the proxy or registrar alive (used for example, to keep NAT bindings open). For connection-oriented transports such as TCP/TLS this is based on CRLF. This mechanism uses a client-to-server "ping" keep-alive and a corresponding server-to-client "pong" message. This ping-pong sequence allows the client, and optionally the server, to tell if its flow is still active and useful for SIP traffic. If the client doesn't receive a pong in response to its ping, it declares the flow “dead” and opens a new flow in its place. In the CRLF Keep-Alive mechanism the client periodically (defined by the PingPongKeepAliveTime parameter) sends a double-CRLF (the "ping") then waits to receive a single CRLF (the "pong"). If the client doesn't receive a "pong" within an appropriate amount of time, it considers the flow failed.

Note: The device sends a CRLF message to the Proxy Set only if the Proxy Keep-Alive feature (EnableProxyKeepAlive parameter) is enabled and its transport type is set to TCP or TLS. The device first sends a SIP OPTION message to establish the TCP/TLS connection and if it receives any SIP response, it continues sending the CRLF keep-alive sequences.

Defines the periodic interval (in seconds) after which a “ping” (double-CRLF) keep-alive is sent to a proxy/registrar, using the CRLF Keep-Alive mechanism.

The default range is 5 to 2,000,000. The default is 120.

The device uses the range of 80-100% of this user-defined value as the actual interval. For example, if the parameter value is set to 200 sec, the interval used is any random time between 160 to 200 seconds. This prevents an “avalanche” of keep-alive by multiple SIP UAs to a specific server.

Defines the maximum number of user register requests (REGISTER messages) that the device sends (to a proxy or registrar server) at a user-defined rate configured by the [GeneratedRegistersInterval] parameter. The parameter is useful in that it may be used to prevent an overload on the device's CPU caused by sending many registration requests at a given time.

The valid value is 30 to 300 register requests per second. The default is 150.

For configuration examples, see the description of the [GeneratedRegistersInterval] parameter.

Defines the rate (in seconds) at which the device sends user register requests (REGISTER messages). The parameter is based on the maximum number of REGISTER messages that can be sent at this rate, configured by the [MaxGeneratedRegistersRate] parameter.

The valid value is 1 to 5. The default is 1.

Configuration examples:

Enables the synchronization of the registration process. This prevents the device from sending multiple SIP REGISTER requests for multiple Accounts and users in the SBC User Information table registering to the same proxy server (serving IP Group) that is currently offline.

These are Accounts that are configured in the Accounts table (see Configuring Registration Accounts) and users that are configured in the SBC User Information table (see Configuring SBC User Information Table through Web Interface).

If an Account or user receives a response timeout (see note below) or a response failure (e.g., SIP 403) for a sent SIP REGISTER request, the device stops sending SIP REGISTER messages for all the other Accounts and users that are associated with the same proxy server (serving IP Group). The Account or user that first detected the no response (or failure) from the proxy is considered the lead Account or user. The device continues sending REGISTER requests to the proxy only for this lead Account or user.

When the lead Account or user receives a successful response from the proxy, the device resumes the registration process for all the other Accounts and users that are associated with this same proxy.

Note: You can configure the response timeout using the [SipT1Rtx], [SipT2Rtx], or [SIPMaxRtx] parameters.

Defines SIP response codes that if received for a failed INVITE message sent for an Account, triggers the device to re-register the Account. The parameter is applicable only if the Account's 'Re-Register on Invite Failure' parameter in the Accounts table is configured to Enable (see Configuring Registration Accounts).

The valid value is a SIP response code. Multiple response codes can be configured, where each value is separated by a comma. The default is "403,408,480" (without quotation marks).

Note: SIP response code 408 also refers to an INVITE timeout (i.e., no reply from server). Therefore, if re-registration is needed for such a scenario, make sure that you configure the parameter with "408" as well.

Enables the device to retry registering even if the last SIP 401\407 response included "stale=false".

When the device initiates a REGISTER request with an Authorization header (according to the relevant configured credentials), and it receives a SIP 401\407 response with the stale parameter set to "false", by default the device doesn't try to send another REGISTER message. When the parameter is enabled, the device retries registering even if the last 401\407 response had "stale=false".

Note: This parameter is applicable only to REGISTER requests which the device initiates (e.g., for an Account or for Gateway endpoints); it's not for REGISTER requests that the device forwards from the user to the registrar server.

Defines a graceful time (in seconds) which is intended to prevent the device from sending REGISTER requests to a registrar server where the device previously registered, if the device also registered successfully to another server since the last successful registration to the registrar server. This can occur if the registrar server has been offline for a brief time. For more information, see the 'Registrar Search Mode' parameter in Configuring Registration Accounts.

The valid value is 0 to 15.2 million. The default is 0.